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Abstract 



We present a concurrent framework for Win32 program- 
ming based on Concurrent ML, a concurrent language 
with higher-order functions, static typing, lightweight 
threads and synchronous communication channels. The 
key points of the framework are the move from an event 
loop model to a threaded model for the processing of 
window messages, and the decoupling of controls noti- 
fications from the system messages. This last point al- 
lows us to derive a general way of writing controls that 
leads to easy composition, and can accommodate Ac- 
tiveX Controls in a transparent way. 



1 Introduction 



Programming user interfaces on the Windows operating 
system at the level of the Win32 API, its lowest level, is 
hard under the best conditions and maddening the rest of 
the time. At least three points underlie the difficulty: 

• the API is large (more than a thousand functions) 
and growing; 

• the system is input-driven, making it difficult to 
perform intensive computations and remain inter- 
active; 

• the system is centered around an event loop, yield- 
ing control-flow that is hard to understand. 

The first problem is hard to circumvent, considering that 
the API is large because it covers a lot of functional- 
ity required by applications. However, a better struc- 
turing can help reduce the burden of using the API, as 
demonstrated by the popularity of C++ class frameworks 
such as Microsoft Foundation Classes (MFC) or Bor- 
land's Object Windows Library (OWL). The remaining 



two problems are in fact related, consequences of Win32 
being a message-passing API based on callback proce- 
dures [12]. 

It has been recognized that to ensure interactivity of ap- 
plications in the presence of computation-intensive code, 
multiple threads should be used [2, 5]. It turns out that 
by using a truly concurrent approach rather than the 
system-level threads available from the NT kernel, one 
can construct a framework that also solves the last prob- 
lem, the event loop control-flow nightmare [15, 7, 5]. 

EXene [6] is a user interface toolkit for the X Win- 
dows windowing system [20], built on top of Concurrent 
ML, a concurrent language providing higher-order func- 
tions, static typing, lightweight threads and synchronous 
communication channels [18]. EXene uses a threading 
model from the grounds up, leading to a design both el- 
egant and simplifying a lot of the difficulties typically 
encountered in user interface toolkits. It is important 
to note that eXene interacts directly via the X protocol, 
without relying on an underlying toolkit. 

The goal of this paper is to isolate the difficulties in 
providing an eXene-style framework for programming 
Win32 applications. We focus specifically on the two 
following points: moving from an event loop model to a 
threaded model with channel-based communication, and 
decoupling the handling of system messages from the 
interaction with controls to help implement easily com- 
posable controls. The resulting system, although fairly 
conservative in its abstractions, is still much simpler to 
use than the raw Win32 API, and further supports the 
thesis that moving to a framework based on a high-level 
concurrent language leads to a simpler system with good 
modularity properties. 

This paper is structured as follows: after reviewing the 
structure of Win32 programs, we describe Concurrent 
ML and give an outline of the framework, focusing on 
the important points of window management. We then 
describe how controls are handled, including predefined 



controls and custom controls. We also describe how to 
handle ActiveX Controls within the same framework in 
as transparent a way as possible. We conclude with some 
discussion of related and future work. 

We assume the reader has a passing knowledge of 
higher-order languages in general. 



2 Win32 programming 

We review in this section the fundamentals of Win32 
programming, at the level of tutorial books such as [14]. 
The Win32 API is closely linked with a given pro- 
gram structure. A Win32 program has an entry point 
WinMain, whose role is to initialize the application by 
creating the various windows making up the interface. 
The program then goes in a loop, reading messages from 
its message queue and dispatching them to the appropri- 
ate window for processing. 

Classes. Every window belongs to a class, which needs 
to be registered prior to being used. A class sets the de- 
fault icons, cursors, background colors and menu for ev- 
ery window of that class. A class also contains a pointer 
to a window procedure, which is a function invoked ev- 
ery time a message is sent to the window. Since a win- 
dow procedure is associated with a given class, this im- 
plies that every window of that class share the same win- 
dow procedure. 

Window procedures. A window procedure is called 
whenever a message is sent to an application, either by 
another window or by the system. Messages are sent 
when a window is created, moved, resized or destroyed, 
when the mouse moves over the client area of the win- 
dow, when the mouse buttons are clicked, when a key 
is pressed and the window has focus, when the window 
needs repainting, when a timer expires, and so on. Win- 
dows provides default handling for all of these messages, 
but an application will want to deal with some of them 
to provide its functionality. 

Child windows. To simplify the creation of user in- 
terfaces, it is possible to use child windows to subdi- 
vide the area of a window into more manageable com- 
ponents. Each child window has its own window pro- 
cedure, thereby encapsulating the behavior of the child 
window and allowing a certain amount of abstraction. 
The child window can decide to only send a few digested 
messages back to its parent window, which can deal with 
them more easily than otherwise possible. Typical ex- 



ample of child windows include controls, such as but- 
tons, scrollbars and edit controls. 

That's all there is to Win32 programming, really. Ev- 
erything else is concerned with the processing of mes- 
sages and their arguments, to do things such as draw- 
ing in a window (by processing the WM_PAINT mes- 
sage), handling mouse movement (by processing the 
WMjyiOUSEMOVE message), handling keyboard input 
(by processing the WM_KEYDOWN message). Handling 
controls such as pushbuttons and edit controls is also 
done through messages. A pushbutton, for example, no- 
tifies its parent window of an interesting event (e.g. it 
has been chcked) by sending a WM_COMMAND message 
to the parent, with a code identifying the control and the 
notification code as arguments. 



3 Concurrent ML 



The language we use to express our concurrent frame- 
work is Concurrent ML (CML) [18], a concurrent ex- 
tension of the mostly-functional language Standard ML 
(SML) [11]. SML provides among other things higher- 
order functions, static typing, algebraic datatypes and 
polymorphic types. CML is provided as a library-style 
extension to SML, with the following (simplified) signa- 
ture: 

structure CML : sig 
type ' a chan 
type ' a event 
type thread_id 

val channel : unit -> ' a chan 
val spawn : (unit -> unit) -> thread_id 
val sendEvt : ' a chan * ' a -> 'a event 
val recvEvt : ' a chan -> ' a event 
val wrap : 'a event * ('a -> 'b) -> 'b event 
val choose : 'a event list -> 'a event 
val sync : ' a event -> ' a 
end 

CML is based on the notion of a thread which is concur- 
rently executing thread of control. A function spawn is 
used to create a thread that evaluates a given function. 
Communication between threads is done via channels. 
Communication is synchronous: a send blocks until a re- 
ceive reads the value on the channel, and vice versa. To 
help design abstract communication protocols, a first- 
class notion of event is introduced. An event decou- 
ples the communication capability of an operation from 
its actual execution (synchronization). Sending a value 
over a channel is actually a two-step process: we first 
create an event that says that the communication opera- 
tion to be done will send a value over the channel, and 



when we synchronize on that event, the value is sent over 
the channel. Synchronization blocks until the communi- 
cation is performed. Basic event constructors include 
sendEvt and recvEvt for sending and receiving a 
value over a channel. Synchronization is performed by 
the sync operation. 

Decoupling definition from synchronization allows for 
the building of combinators to describe more refined 
communication mechanisms. For example, given an 
event, the wrap operation wraps a function around that 
event creating a new event that behaves as follows: when 
you synchronize on the event, the original event is syn- 
chronized on, and the result of the synchronization is 
fed to the function which is evaluated. Given a set 
of events, you can also create a new event that is a 
non-deterministic choice over all those events with the 
choose operation: when you synchronize on the event, 
one of the original events is non-deterministically cho- 
sen and synchronized on. Finally, note that channels 
and events are polymorphic over the carried type (repre- 
sented by the type variable ' a): a channel of type int 
Chan carries values of type int, and so on. 

Concurrent ML is currently distributed with the Stan- 
dard ML of New Jersey compiler [1 J. 



4 The basic framework 



We outline in this section our framework for pro- 
gramming Win32 user interfaces using the concurrency 
model provided by CML. The framework is built on 
top of a direct binding of the Win32 API in SML. An 
overview of the binding as well as examples of use are 
given in [16]. The binding was derived from an IDL 
description of the API using a tool for compiling IDL 
descriptions to SML code interfacing the described API 
[17]. This turned out surprisingly well' and allowed us 
to use code found in tutorial material such as [14]. 

For our framework, we build on top of the raw Win32 
API some layers of abstractions that simplify and ab- 
stract away from many low-level details. We still remain 
very much in the spirit of Win32 however, in the sense 
that most functions are simply lifted from the underlying 
API. Abstractions are mainly concerned with replacing 
the event loop by an independent thread and allowing a 

^ There were some interesting issues raised in providing the Win32 
API bindings — both in terms of support of the Win32 API in a 

strongly-typed setting, and in terms of the mapping from IDL to SML 
— that may or may not be described in a future article. 



more compositional treatment of controls. 

The framework aims at supporting more or less the func- 
tionality described in the first volume of [10], along 
with various simphfying assumptions. This paper fur- 
ther simplifies matters for the purpose of presentation, 
and in order not to overwhelm the reader with superflu- 
ous and confusing details. Note that we only give the 
signature of the modules in this paper, that is the type of 
the operations and values provided by the various mod- 
ules. Implementation details are not discussed. 

Figure 1 presents the Run module, which is the main 
entry point of the framework. The main function of a 
program in our framework is a function of type 

instance -> 'a 

taking as argument the instance handle of the program 
and returning some type (exactly which type is returned 
is unimportant). This function will be in charge of cre- 
ating the various windows of the application, and call- 
ing the message loop of the main window. The func- 
tion do i t of the Run module invokes the main function, 
supplying the application instance handle. 

Various modules are provided that simply encapsulate 

some aspect of the API, lifting the functions without try- 
ing to generalize or abstract away some of the function- 
ality. For example, Figure 2 and 3 present modules that 
deal respectively with icons and menus. Other modules 
such as Cursor, Bitmap, Rect, Pen, DC encapsu- 
late different aspects of the API. All of these are fairly 
straightforward, and aside from their sheer number, their 
implementation does not offer any difficulties. It is def- 
initely the case that future work should aim at finding 
new abstractions to reduce either the size or the com- 
plexity of this part of the framework. 

The most important module from our point of view is the 
one that focuses on window management. Window man- 
agement describes anything that relates to the manip- 
ulation of windows, including their creation, deletion, 
movement, as well as the management of the classes. As 
we saw, every window belongs to a class, that assigns a 
default icon, cursor and colors for every window of that 
class. Moreover, in raw Win32, the class also provides 
a window procedure to process messages to the window. 
The window procedure is shared amongst all windows 
of the class. It is not clear why this design was chosen. 
Informal explanations are given that this helps guarantee 
that every window of a given class can behave the same 
way. But since the window procedure upon reception 



structure Run : sig 

type instance 

val doit : (instance -> ''a) -> ''a 
end 



Figure 1: The Run module 



structure Icon : sig 
type icon 

val application : icon 
val hand : icon 
val question : icon 
val exclamation : icon 
val asterisk : icon 

val load : Run . instance * string -> icon 
val draw : DC . hdc * int * int * icon -> unit 
end 



Figure 2: The Icon module 



structure Menu : sig 
type menu 

val load : Run. instance * string -> menu 
val get : Window . window -> menu 
val create : unit -> menu 
val createPopup : unit -> menu 
val appendltem : menu * int * string -> unit 
val appendPopup : menu * menu * string -> unit 
val destroy : menu -> unit 
end 



Figure 3: The Menu module 



structure Window : sig 
type class 
type window 

datatype class_stYle - CS_HREDRAW 

I CS_VREDRAW 
I ... 

datatype window_style = WS_OVERLAPPEDWINDOW 
I ... 

datatype show_style = SW_NORMAL 
I ... 

val class : string * Run .instance * Cursor. cursor * Icon .icon * Brush . brush * class_stYle list -> class 
val unregister : class -> unit 

val create : class * string * window_style list * window option * int option * int option * int option * 

int option * Menu . menu option * Run .instance * {window * Msg .msg chan -> unit ) -> window 
val createChild : class * string * window_style list * window * int option * int option * 

int option * int * int * Run .instance * (window * Msg .msg chan -> unit ) -> window 
val show : window * show_style -> unit 
val update : window -> unit 
val setForeground : window -> unit 
val move : window * int * int -> unit 
val getClientRect : window -> Rect . rect 
val destroy : window -> unit 
val send : window * Msg . msg -> unit 
val quit : int -> unit 
val msg_loop : window -> int 
val default : window * Msg .msg -> unit 
end 



Figure 4: The Window module 



of a message also receives the handle of the window to 
which the message is addressed, it is very easy to write 
a window procedure that handles messages differently 
depending on the recipient of the message. 

In our framework, we would like to have a thread re- 
placing the window procedure, and actual messages over 
channels instead of the Win32 messages passed to win- 
dow procedures. In order to keep messages Ughtweight, 
we would like to drop the requirement of passing the 
handle of the target window when a message is sent. 
Indeed, our function to send a message should extract 
the communication channel from the window type, and 
send the message to that channel, implicitly determin- 
ing which window the message is sent to. To help this 
setup, we will have a thread assigned on a per window 
basis. Of course, one can still support shared processing 
amongst all windows of a given class by delegating ev- 
ery messages to a centralized thread that communicates 
with every window of a class. 

Figure 4 presents an excerpt of the Window module 
containing the interesting parts of the code. Types are 
defined for classes, windows, and various style parame- 
ters for both classes and windows. A function class 
creates a class given the appropriate parameters, and 
automatically registers it. The functions create and 
createChild are used to create windows, given the 
class, title, optional owner window, position and size 
(a value of NONE for these forces the use of a default, 
equivalent to a CW.USEDEFAULT in raw Win32), op- 
tional menu, instance handle and a function to process 
messages. This last function is spawned automatically 
on its own thread and is passed the window being created 
and a channel to communicate with the window. A child 
window is similar, but instead of a menu it takes an inte- 
ger that should uniquely identify the child window and 
that will be use to communicate with the parent window. 
Functions are then provided to show, move and destroy 
the window. A function msg_loop is used to initiate the 
message loop of a window^. A function send is used to 
send a message to a window. The function quit simply 
posts the WM_QUIT message in the message queue of the 
application, a requirement for exiting a message loop. 

As an example, consider the following main function for 
an application that bounces a logo around a window. 
This example is taken from chapter 7 of [14], and is 
given in its entirety in Appendix A. It is as simple an 
initialization function as can be: only one class, a win- 
dow created with mostly default values, and a simple 
message loop. 

^This assumes that windows in tiie framework use standard mes- 
sage loops, a simplifying assumption. 



fun winmain (instance) = let 
val c = Window. class 

( "BouncingSMLN" , instance. 
Cursor . arrow, Icon . application. 
Brush . white, 
[Window. CS_HREDRAW, 
Window. CS_VREDRAW] ) 
val w = Window . create 

(c, "Bouncing SML/NJ", 
[Window. WS_0VERLAPPEDWINDOW] , 
NONE, NONE, NONE, NONE, NONE, 
NONE, instance, bounce) 
val V = Window. msg_loop (w) 

in 

Window . unregister (c) ; 

V 

end 

The module Msg, outlined in FigureS, defines the var- 
ious messages that can be sent to windows by the sys- 
tem and by other windows through the window . send 
function. There is a datatype constructor per mes- 
sage, and message parameters are automatically un- 
folded for easy retrieval and building. The function 
given to Window . create will be spawned and passed 
the newly created window and a newly created chan- 
nel on which the thread will receive its messages. At 
this point, Win32 rules for processing messages apply: 
every message not processed by the application must 
be passed to default processing, which means invoking 
Window . default with the message as argument, and 
so on. Often, the thread will simply read from the input 
channel and process the messages, but it can also listen 
concurrently for events coming from other parts of the 
application or from controls. 

Finally, although we wiU not discuss them here, we men- 
tion that most errors in Win32 functions get mapped to 
SML exceptions. 



5 Controls 

The first step in the creation of our concurrent frame- 
work for Win32 involved lifting window procedures into 
actual threads with which one can communicate using 
CML-style message-passing. We now turn to the sec- 
ond important aspect of our framework: compositional 
controls. 

A control is "... a child window an application uses in 
conjunction with another window to carry out simple in- 
put and output (I/O) tasks." [10]. In reality, controls can 
achieve any level of complexity chiefly through compo- 
sition: putting a bunch of controls together forms a big- 
ger control with potentially a higher-level semantics. It 
is possible in raw Win32 to compose controls, but the 
amount of plumbing one has to write is mind-numbing. 



Our aim is to make creating new controls by combining 
existing ones easy, while staying within the philosophy 
of Win32. 

A requirement for this to work is that there be no differ- 
ence between a predefined control (such as a pushbut- 
ton or an edit control) and a composed control. We also 
would like the communication to and from the control 
to be independent of the window procedure of the par- 
ent window. The basic idea is that a control will have 
a notification channel on which it communicates inter- 
nal changes and interesting events. Communication to 
the control is achieved by invoking appropriate functions 
acting on the control. 



5.1 Predefined controls 



Many controls are predefined in Win32. These include 
various kind of buttons (push, check, radio), editing con- 
trols, list and combo boxes, scrollbars, and static con- 
trols. Providing them in our framework is fundamen- 
tally a matter of presenting them the right way to the 
user. For example. Figure 6 and 7 give the modules im- 
plementing respectively pushbuttons and edit controls. 
Note the similar format of the modules: both define a 
type for the control, a datatype defining the various no- 
tification messages that the control can report, a CML 
event that a thread can synchronize on to get the noti- 
fication, functions to communicate with the control, a 
function to create the control, and a function to access 
the control as a normal window, allowing one to apply 
functions from the Window module. 

The problem with such an interface is that it com- 
pletely contradicts the default interface for controls im- 
plemented in raw Win32. A predefined control sends 
notifications directly to its parent window by sending a 
WM_COMMAND message to the window procedure, with 
its control ID as an argument and the notification as the 
other. What we want is to intercept that message and 
redirect it onto a CML channel. 

One way to achieve this is for the system to to transpar- 
ently create a child window around the control, which 
will be the parent of the control, in charge of captur- 
ing the WM.COMMAND messages and sending them onto 
a CML channel assigned when the control is created. 
All very straightforward, but some work is involved in 
making sure that all the messages sent to the control are 
communicated to the transparent child window. For ex- 
ample, applying Window. move to the control should 
move the control but also move the transparent child 



window, and similarly for resizes and most other win- 
dow operations. 



5.2 Custom controls 



Custom controls are controls defined by the program- 
mer. To create a new control, a programmer must de- 
termine the appearance of the control and its interaction 
with its subcontrols, if any, and its parent. The simplest 
example of a custom control is a layout control, which 
is in charge of maintaining the layout of its subcontrols 
according to some constraint criterion. Other more in- 
volved controls can include dozens of subcontrols inter- 
acting in a complex way. Dialog boxes can also be seen 
as a type of complex control. 

By uniformity, we would like custom controls to respect 

the informal specifications given in the previous subsec- 
tion. Technically, a custom control is a child window, 
created via the Window . createChildfunction. The 
thread associated with the window, in charge of handling 
messages to the window, defines the appearance of the 
control by handling the WM.PAINT message, and so on. 
Communication with subcontrols is achieved by listen- 
ing for the notification events from the subcontrols, con- 
currently with handling messages for the window. Sim- 
ilarly, a channel for reporting notification events for the 
custom control needs to be allocated. 

For example, a new control that encapsulates two push- 
buttons might have a single notification message defined 
as: 



datatype notify_msg = CLICKED of Int 

which simply reports which button has been clicked, 
and a controlhng thread processing messages to the 
window that also listens to notification events from 
the two subcontrols and sends the appropriate notifica- 
tion when chcks occur (assuming a notification channel 
notif yCh, and pushbuttons bl and b2): 



sync (choose ( [wrap (recvEvt (ch) , hanclle_rfiessage) , 
wrap (PushButton . notif yEvt (bl), 

fn (PushButton. BN_CLICKED) => 

send (notifyCh, CLICKED 1) 
I _ => 0), 
wrap (PushButton. notif yEvt (b2), 

fn (PushButton. BN_CLICKED) => 

send (notifyCh, CLICKED 2) 
I _ => ) ] 



structure Msg : sig 

datatype msg = WM_SIZE of int * int 
I WM_PAINT of Rect.rect 
I WM_DESTROY 
I WM_TIMER of int 
I ... 

end 



Figure 5: The Msg module 



structure PushButton : sig 

type push_button 

datatype notify_msg = BN_CLICKED 

I BN_DOUBLECLICKED 
val notif yEvt : push_button -> notif Y_msg event 

val create : string * int * int * int * int * Run . instance -> push_button 
val windowOf : push_button -> Window . window 
end 



Figure 6: The PushButton module 



structure Edit : sig 

type edit 

datatype notify_msg = EN_CHANGE 

I EN_ERRSPACE 
I EN_HSCROLL 
I EN_KILLFOCUS 

I EN_MAXTEXT 

I EN_SETFOCUS 

I EN_UPDATE 

I EN_VSCROLL 
val not if yEvt : edit -> notif y_insg event 
val getSel : edit -> (int * int) 
val setSel : edit * int * int -> unit 
val replaceSel : edit * string -> unit 
val canUndo : edit -> bool 
val emptyUndoBuf f er : edit -> unit 
val undo : edit -> unit 

val create : string * int * int * int * int * Run . instance -> edit 
val windowOf : edit -> Window . window 
end 



Figure 7: The Edit module 



Decoupling the logic of the communication with the 
subcontrols from the handling of system messages to 
the control greatly helps modularizing the code. Indeed, 
given a custom control, we could easily reuse the com- 
munication logic for some other control having the same 
"behavior", but maybe a wildly different appearance [9]. 

5.3 ActiveX Controls 



No discussion of controls would be up-to-date without 
mentioning ActiveX Controls [3]. The ActiveX Con- 
trols technology goes back to Visual Basic Extensions 
(VBX), a mechanism for writing control components for 
use in the Visual Basic environment. These were gener- 
alized to OLE Controls for use in a general COM-based 
environment [19]. The main problem with OLE Con- 
trols is that they required the programmer to implement 
a large number of interfaces that had to be present for 
the control to be usable. This did not mix well with the 
lightweight requirement for downloadable controls over 
a network, and so ActiveX Controls were introduced, 
fundamentally OLE Controls with looser requirements. 

ActiveX Controls are simply COM objects^, and the 
support for ActiveX Controls in any framework is based 
on the corresponding support for COM objects. An ap- 
phcation that can use ActiveX Controls is called a con- 
trol container. The functionaUty of an ActiveX Control 
is divided into four parts (from [3]): 

• providing a user interface; 

• allowing the container to invoke the control's meth- 
ods; 

• sending events to the container; 

• learning about properties of the container's envi- 
ronment and allowing the control's properties to be 
examined and modified. 

As we discussed in [16], calling the methods of a COM 

object from SML is fairly easy. It is harder to make the 
framework into a control container, because that implies 
presenting the whole framework as a COM object with 
the appropriate interfaces that ActiveX Controls can ac- 
cess to communicate events. This is not impossible, but 
most implementations of SML do not allow this to be 
done easily. Given a suitable implementation of such a 
capability, it is not hard to see how ActiveX Controls fit 

3 They must also support self-registration. 



in the above framework. Current work on the SML/NJ 
runtime system is in part aimed at solving this particular 
problem. 



6 Related work 



The idea that concurrency helps in programming user 
interfaces is not new. Building on the original work of 
Squint [15] and Montage [7], eXene [6] exemplifies the 
consistent use of concurrency as a foundation for user 
interface construction [5]. More recently. Haggis [4], a 
functional framework built on top of a concurrent ex- 
tension to Haskell, also demonstrated the usefulness of 
concurrency in such a context. However, as opposed to 
eXene and our approach, the model presented to the user 
is strictly sequential — concurrency is only used inter- 
nally. 

Compositionality of user interface elements is a require- 
ment for a programmer-friendly toolkit. Systems such 
as Tk [13] are mostly based on the notion that a user in- 
terface is a widget (in our terminology, a control) com- 
posed of subwidgets. Building a user interface is a mat- 
ter of composing the controls together in a hierarchi- 
cal fashion. Tk however uses Tel as its underlying lan- 
guage, and because of its lack of large-scale program- 
ming structures, it is not well suited to building large 
systems (although some large systems have indeed been 
built using Tcl/Tk). The basic ideas underlying compo- 
sitionality are best presented from the point of view of 
the so-called Model- View-Controller approach, and we 
refer the reader to articles such as [9] for a deeper cov- 
erage of the issues. 

Of course, another closely related system is the Mi- 
crosoft Foundation Classes framework, which provide 
C++ classes structuring most of the Win32 API. MFC 
also allows the definition of methods to handle messages 
directly, removing the need to explicitly code up the win- 
dow procedure. However, the model is still based on an 
event loop, and it is still hard to program computation- 
intensive applications that remain interactive. Kernel 
threads must be used to help manage the complexity. 
More experience with our system is required before fur- 
ther comparison can be made, especially with respect to 
the efficiency, maintainabihty and reuse possibiUties of 
the code. 



7 Conclusion 



and information on the framework presented 
here can be found on the author's web page at 
http : //cm. bell-labs . com/cm/cs/who/riccardo. 



We have described in this paper the design of a simple 
concurrent framework for Win32 programming, based 
on a high-level concurrent language with lightweight 
threads. The description we have given is very much 
an outline, and indeed even our implementation is in- 
complete. We have not talked about color, dialog boxes, 
keyboard and mouse handling, multiple-document inter- 
faces, floating menus, common dialogs, to name a few. 

The important points about our framework are the move 

from an event loop foundation to a threaded model, and 
a decoupling of the processing of system messages from 
the notification messages from controls. This gives us 
a chance to derive easily composable controls. It also 
gives us a natural way to incorporate ActiveX Controls 
transparently into the framework. 

Although the framework does not introduce a great 
many abstractions over the underlying Win32 API, the 
framework is still much easier to use than a raw Win32 
system, and the resulting code more modular, thereby 
increasing reusability. 

Future work. As we mentioned, the framework is quite 
simplistic, and does not go as far as it could go to ab- 
stract away from the underlying system. This was an ex- 
periment to try to impose a concurrent communication 
mechanism onto Win32 that supports an abstract view 
of controls decoupled from the window procedure, and 
nothing else. We tried to stay as close as possible to the 
raw Win32 programming style. Future work is planned 
in two directions. First, this project is but a first step in 
implementing a Win32 interface to Standard ML of New 
Jersey. The next step is the design of a real toolkit that 
can manage both X-windows and Windows (and even- 
tually others), with an even more abstract notion of con- 
trols. An investigation into the use of reactive sublan- 
guages [8] to express the logic behind the controls inter- 
actions in such a toolkit is also in the works. Second, we 
plan to investigate the feasibility of transferring some of 
this work to a C/C++ framework, perhaps at the cost of 
introducing a custom version of lightweight threads. 

Acknowledgments. Thanks to John Reppy for many 
discussions relating to the subject of concurrency in user 
interfaces that led to the experiment described in this pa- 
per. 

Availability. The Standard ML of 

New Jersey distribution is available from 
http : / / cm . be 11 -labs . com/ cm/ cs/what / smln j 
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A Bounce example 



fun bounce (window, ch) = let 
val timerlD ^ 1 
val rate - 20 
val moveR ^ 10 
val xTotal = 158 
val yTotal = 131 
val xRadius = 59 
val yRadius = 45 

fun onTimer (xS, yS, xC, yC, xM, yM, b) 



let 



val hdc ^ DC . get (window) 

val hdcMem = DC . createCompatible (hdc) 

val _ = (Bitmap . select (hdcMem,b); 

DC.bitBlt (hdc,xC - (xTotal div 2), yC 



val xC 
val yC 
val xM' 
val yM' 



xTotal, yTotal, 
DC. release (window, hdc) ; 
DC . delete (hdcMem) ) 

= xC + xM 

= yC + yM 

= if (xC + xRadius >= xS) 
= if (yC + yRadius >= yS) 



hdcMem, 



orelse (xC 
orelse (yC 



0, 



(yTotal div 2) , 
DC.SRCCOPY) ; 



xRadius 
yRadius 



0) then ~xM else xM 
0) then ~yM else yM 



(xS, yS, xC , yC , xM' , yM' , b) 
end 

fun computeArgs (x,y,b) ^ (x,y,x div 2, y div 2 
fun loop (args as (xS, yS, xC, yC, xM, yM, b) ) = 
case (recv (ch) ) 

of Msg.WM_SIZE (x,y) 



moveR, moveR, b) 



I Msg.WM_DESTROY 



I Msg.WM_TIMER (t) 



=> loop (computeArgs (x,y,b)) 
(Timer. kill (window, timerlD) ; 
Bitmap . delete (b) ; 
Window. quit (window, 0) ) 
> let 



val args ' = if ( t=t imerlD) then onTimer (args ) else args 
in loop (args') end 
I m => (Window. default (window, m) ; loop (args) ) 
fun init ( ) = 

case (recv (ch) ) 

of Msg.WM_CREATE => (Timer. set (window, timerlR, rate, NONE) ; 
loop (0,0,0,0,0,0, 

Bitmap .load ( " smln j . bmp" ) ) ) 

I m => init () 

in 

init 
end 

fun winmain (instance) = let 

val c = Window. class ( "BouncingSMLN" , instance. 

Cursor . arrow. Icon . application. 
Brush . white , 

[Window. CS_HREDRAW, Window . CS_VREDRAW] ) 

val w = Window. create (c, "Bouncing SML/NJ", 

[Window. WS_OVERLAPPEDWINDOW] , 
NONE, NONE, NONE, NONE, NONE, 
NONE, instance, bounce) 

val V = Window. msg_loop (w) 



Window . unregister (c) ; 



